The IP Multimedia Subsystem (IMS) is the technology defined by the Third Generation Partnership Project (3GPP) to provide IP Multimedia services over mobile communication networks. IP Multimedia services provide a dynamic combination of voice, video, messaging, data, etc. within the same session. As the number of basic applications, and the media which it is possible to combine, increases, so will the number of services offered to the end users, giving rise to a new generation of personalised, rich multimedia communication services.
The IMS makes use of the Session Initiation Protocol (SIP) to set up and control calls or sessions between user terminals (or user terminals and application servers). The Session Description Protocol (SDP), carried by SIP signalling, is used to describe and negotiate the media components of the session. Whilst SIP was created as a user-to-user protocol, IMS allows operators and service providers to control user access to services and to charge users accordingly.
FIG. 1 illustrates schematically how the IMS fits into the mobile network architecture in the case of a GPRS/PS access network. As shown in FIG. 1 control of communications occurs at three layers (or planes). The lowest layer is the Connectivity Layer 1, also referred to as the bearer plane and through which signals are directed to/from user terminals accessing the network. The GPRS network includes various GPRS Support Nodes (GSNs). A gateway GPRS support node (GGSN) 2 acts as an interface between the GPRS backbone network and other networks (radio network and the IMS network).
The IMS 3 includes a core network 3a, which operates over the middle, Control Layer 4 and the Connectivity Layer 1, and a Service Network 3b. The IMS core network 3a includes nodes that send/receive signals to/from the GPRS network via the GGSN 2a at the Connectivity Layer 1 and network nodes that include Call/Session Control Functions (CSCFs) 5, which operate as SIP proxies within the IMS in the middle, Control Layer. The 3GPP architecture defines three types of CSCFs: the Proxy CSCF (P-CSCF) which is the first point of contact within the IMS for a SIP terminal; the Serving CSCF (S-CSCF) which provides services to the user that the user is subscribed to; and the Interrogating CSCF (I-CSCF) whose role is to identify the correct S-CSCF and to forward to that S-CSCF a request received from a SIP terminal via a P-CSCF.
At the top is the Application Layer 6, which includes the IMS service network 3b. Application Servers (ASs) 7 are provided for implementing IMS service functionality. Application Servers 7 provide services to end-users, and may be connected either as end-points, or “linked in” by an S-CSCF. Certain Application Servers 7 will perform actions dependent upon subscriber identities (either the called or calling subscriber, whichever is “owned” by the network controlling the Application Server 7).
The IMS architecture makes it possible to deploy peer-to-peer applications where two or more users exchange data during a SIP session. Examples of such peer-to-peer applications include Multimedia Telephony (MMTel), Push to Talk over Cellular (PoC), streaming, real-time video sharing, file sharing, gaming etc. The transport connection(s) is (are) negotiated dynamically by means of the SIP/SDP protocol exchange between the two end points (user terminals).
However, in order to support such peer-to-peer applications, there are two basic requirements: (i) a mechanism is needed to selectively control the SIP signal flows associated with the IMS session(s) of a subscriber; and (ii) a functionality is needed to control the IP flows through the dynamically negotiated transport connections in order to apply an effective charging for usage of services. One important aspect concerns the resources required for the session, which will impact on the Quality of Service (QoS) provided for the session (e.g. the data rate at which data is transferred between the end users). In the discussion below the term QoS is used to refer to those parameters of a requested or on-going session that determine the Quality of the session Service experienced by the end user. The principal bearer resource characteristic affecting QoS is the available bandwidth for the session.
3GPP has recognised such needs and is currently defining a Policy and Charging Control (PCC) Architecture (see 3GPP TS 23.203 [1]). FIG. 2 presents the basic outline of the PCC architecture. The Application Function (AF) 16 is an element offering applications that require dynamic policy and/or charging control of traffic plane resources. Although the application services are initiated and service characteristics are negotiated at the Application Layer 6 (e.g. by an Application Server 7—see FIG. 1), in the case of the IMS the P-CSCF plays the role of the AF 16 at the SIP signalling plane (Control Layer 4). A Policy and Charging Enforcement Function (PCEF) 12 in the Connectivity Layer 1 monitors service data flow and enforces network policy on the user plane traffic. The PCEF 12 also applies charging based on the monitored data flow and the charging policy applied. This information is provided to an Online Charging System 13 over the Gy interface. Within a GPRS access network, the PCEF 12 is located in the GGSN 2a. Within the Systems Architecture Evolution defined in 3GPP Release 8, the PCEF is located in the PDN gateway.
A Policy and Charging Rules Function (PCRF) 14 resides in between the AF 16 and the PCEF 12. The PCRF 14 is the entity that controls charging based on the monitored data flow. The PCRF 14 obtains rules relating to the charging policy to be applied for particular subscribers over the Sp interface from a Subscription Profile Repository (SPR) 18, which includes a database of subscriber information. The PCRF 14 installs these PCC rules at the PCEF 12 over the Gx interface. These ensure that only authorized media flows associated with the requested services are allowed. In addition, the PCC rules installed at the PCEF 12 ensure that the right bandwidth, charging and priority are applied through the right bearer.
Once session characteristics are negotiated between the communication peers and the session characteristics are authorized within the IMS Core Network 3a, the AF 16 provides to the PCRF 14 an authorization of bearer resources over the Rx interface so that the corresponding resource reservation can be authorized at the Connectivity Layer 1.
However, there could be circumstances when the corresponding resource reservation cannot be authorised at the bearer layer. One such reason, for example, could be that the access operator has established restrictions on bandwidth consumption for their users or for that particular user. Under these circumstances, the current specification in 3GPP TS 29.214 [2], states that:
“The PCRF shall process the received Service Information according to the operator policy and may decide whether the request is accepted or not.”
However, it is not specified what the PCRF 14 does when the request is not accepted. In the absence of any explicitly defined mechanism, it can be assumed that the PCRF 14 must be configured according to the operator's preferences. This may, or may not include feedback of information to the AF 16 regarding the reason for not accepting the request. Currently the PCRF 14 does not know if the AF 16 requires such information and will therefore perform its processing (however configured) regardless of any AF preferences.
For example, it may be possible for session services of a requested peer-to-peer session that has been rejected due bandwidth restrictions to be provided at a lower bandwidth, at least for certain media types, so that the session could be allowed to proceed at a lower QoS. If information concerning the bandwidth restrictions affecting the rejected session request is made available, this could be used to initiate a modified session request. The modified request could be initiated from the AF itself, but would normally be initiated by the UE after it has been made aware of the restrictions either by the AF 16 or directly from the Connectivity Layer 1. Therefore, it can only be the AF 16 that knows whether or not the indication of bandwidth restriction is relevant for the AF 16 in order to modify the session request or to inform the UE of the allowable bandwidth for the session.
Moreover, even when the indication of bandwidth restriction is relevant for the AF 16, it is only the AF 16 that knows in which specific format it requires the information. If the PCRF 14 is configured in a certain way, it is possible that it will not feed back the information required, or not in the correct format, for this to be used by the AF 16. For example, the PCRF 14 might be configured to compute the available bandwidth and provide this information to the AF 16 in one particular format (e.g. total available bandwidth for the session) when the AF 16 actually requires the available bandwidth per media component.
The present invention has been conceived with the foregoing in mind.